[Chapter 22] 22.8 Security Features
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T19:30:05Z

#

| Chapter 22 Security |

## 22.8 Security Features

We now turn our attention from security problems to security features:

- The `T` configuration command (class `t`) defines which users are allowed to use the `-f` command-line switch to override the sender address with one of their own.

- The smrsh program replaces /bin/sh as the program run by the `prog` delivery agent to execute programs.

- Several options can be used to tighten security and to provide reports of security violations.

- The /etc/shells file prevents ordinary users from running programs on your mail server.

### 22.8.1 Trusted Users

Under pre-V8 sendmail, trusted users are those who are allowed to use the `-f` command-line switch (see Section 36.7.21, -f and -r) to override the sender address with one of their own. V8.1 sendmail eliminated this configuration command. V8.7 restored it, but as a class, and uses that class only to suppress warning headers.

Trusted users are necessary for certain kinds of mail to flow properly. By way of example, the rmail(8) program of the UUCP suite of programs runs suid to uucp. If rmail were not to use the `-f` command-line switch, all mail from UUCP would wrongly appear to come from the uucp user. To circumvent this problem, rmail runs sendmail as

>     /usr/lib/sendmail -f reallyfrom

This tells sendmail to show, in both the header and envelope, the message as being from reallyfrom, rather than from uucp.

The concept of a trusted user is intended to prevent ordinary users from changing the sender address and thereby forging mail. Although that intention is laudable and good for UUCP, it can cause problems with mailing lists. Consider the following:

>     list: "|/usr/lib/sendmail -oi -flist-request -odi list-real"
>     list-real:    :include:/export/share/mail-lists/list.list

The intention here is for all mail sent to the mailing list named `list` to be dispatched as though it were sent from the address `list-request` (the `-f`). This causes errors to be returned to the maintainer of the list (the `list-request`), but replies still go to the real sender.

Unfortunately, this scheme fails when mail is posted to `list` from the local machine. Recall that only trusted users can change the identity of the sender with `-f`. This is why V8.1 sendmail eliminated the concept of the trusted user (anyone could use the `-f` switch). Beginning with V8.7, sendmail restored the concept but uses the `T` command only to suppress warning headers.

#### 22.8.1.1 Declare trusted users (not V8.1 through V8.6)

Trusted users are defined by those lines in the sendmail.cf file that begin with the uppercase letter `T`. Only trusted users may use the sendmail program's `-f` command-line switch to specify who sent the message. Beginning with V8.7 sendmail, the class `t` may also be used.

The `T` sendmail.cf command must begin a line. One or more space-delimited usernames then follow on that same line. There may be multiple `T` commands in a sendmail.cf file, each adding names to the list of trusted users. Prior to V8 there could be at most `MAXTRUST` trusted users, where `MAXTRUST` was defined in conf.h when you compiled sendmail. Beginning with V8.7, there is no limit:

>     T uucp                    legal in V8.1 through V8.6 but ignored
>     Troot daemon              legal in V8.1 through V8.6 but ignored
>     Ct uucp                   V8.7 and above
>     Ctroot daemon             V8.7 and above

The two `T` commands show that there may optionally be whitespace between the `T` and the first name in any list of names. They indicate that uucp, root, and daemon are trusted and have been added to the list of trusted users in that order. The two class declarations show a similar declaration for use beginning with V8.7 sendmail (but note that V8.7 and above can still use the old syntax).

Prior to V8 sendmail, if you listed more than `MAXTRUST` trusted users, sendmail printed and syslog(3)'ed a message like this:

>     sendmail: too many T lines, 32 max

This message was not fatal. The sendmail program issued it for each excess `T` line (ignored those trusted users) and continued to run.

Prior to V8 sendmail, if a user who was not trusted attempted to use the `-f` switch, that attempt was silently ignored (silently disallowed). Beginning with V8.7 sendmail, if a user who is not trusted attempts to use the `-f` switch, that attempt may produce an `X-Authentication-Warning:` header (see Section 35.10.35, X-Authentication-Warning:) if the `PrivacyOptions` (`p`) option (see Section 34.8.47) has `authwarnings` listed.

- Even though some users find them annoying, we recommend that you always enable `X-Authentication-Warning:` headers. They warn of suspicious behavior. If the behavior is legitimate, modify that behavior to eliminate the header instead of eliminating the more valuable warning headers.

### 22.8.2 The smrsh Program

One line of attack against all users, including root, is to modify a user's ~/.forward file (see Section 22.5.3, "Permissions for ~/.forward Files"). Unless you take steps to prevent it, sendmail will run any program that it finds in a user's ~/.forward file:

>     \user
>     |"/usr/ucb/vacation user"                                     ok
>     |"/tmp/x.sh"                                                  An attack!
>     |"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"      An attack!

As an aid in preventing such attacks, V8 sendmail offers the smrsh (sendmail restricted shell) program, and V8.7 sendmail offers the `smrsh` FEATURE (see Section 19.6.22, FEATURE(smrsh)) as an easy way to install smrsh with the m4 configuration technique.

The smrsh program is supplied in source form with the sendmail distribution in the smrsh directory. The README file in that directory describes how to compile and install smrsh.

The smrsh program replaces the /bin/sh program in the `prog` delivery agent (see Section 30.2.1, "Required Symbolic Names") declaration:

>     Mprog, P=/usr/local/etc/smrsh, ...

Thereafter, whenever smrsh is called to run a program, smrsh strips the leading path from the program name and looks for that program in its special /usr/adm/sm.bin directory. If the program is not found in that directory, the message bounces. Thus in our first attack example above, with smrsh installed and with x.sh not in the /usr/adm/sm.bin directory, the ~/.forward line

>     |"/tmp/x.sh"

would cause the email message to bounce with this error:

>     smrsh: /usr/adm/sm.bin/x.sh: not found

The smrsh program also screens out program lines that contain suspicious characters (such as our second attack above):

>     |"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"

In this instance, smrsh would reject the command line (and thus bounce the message) because it contained a semicolon character:

>     smrsh: cannot use ; in command

- The smrsh program is simple yet immensely valuable. We recommend that it be routinely installed on all your machines.

- Be very conservative when choosing programs to put in the /usr/adm/sm.bin directory. Never, for example, put programs there that allow shell escapes.

### 22.8.3 Security Options

The sendmail program offers several options that can help you to improve the security at your site. Some we have discussed above. We touch on a few more in this section, and provide a recommended setting where appropriate. For a full description of each, see the sections referenced.

#### 22.8.3.1 The DefaultUser option

The `DefaultUser` (`u`) option (see Section 34.8.15) can be used to ensure that the default identity (when it is not running as root) is a safe one. CERT recommends that you create a pseudo-user whose uid and gid are used nowhere on your system, then define the `DefaultUser` (`u`) option to be that pseudo-user. As an additional precaution, make sure that pseudo-user lacks a valid shell and has no valid home directory:

>     nullmail:*:32765:32765:Sendmail Default User:/no/such/directory:/bin/false

At the same time, set up a group entry for this user's group:

>     nullgroup:*:32765:

This is necessary if you want to refer to this group symbolically at some later time.

Avoid using the name nobody, because root is mapped to nobody over NFS. If root were to create a file over NFS that it thought was safe because root owned it and because it was readable only by root, that root user would be surprised to find that file owned by nobody. Consequently, we recommend that in an NFS environment you set the default user to one less than nobody. For example, if nobody has the uid 65534, you could set up

>     nullmail:*:65533:65533:Sendmail Default User:/no/such/directory:/bin/false

#### 22.8.3.2 The ForwardPath option

The `ForwardPath` (`J`) option (see Section 34.8.27, ForwardPath (J)) lists a series of directories that sendmail will search for user ~/.forward files. At most sites there are users who are savvy and able to correctly administer their own ~/.forward files, but there are others who are untrained or careless. One way to allow experienced users use of the ~/.forward facility while denying it to the others is with the `ForwardPath` (`J`) option:

>     O ForwardPath=/usr/local/etc/forwards/$u.forward:$z/.forward

Here, sendmail will first search the /usr/local/etc/forwards directory to find a file that begins with the user's login name (the `$u` see Section 31.10.36, $u) followed by a .forward. If you set up such a file for the untrained user, say bob:

>     -rw-r-r-  1 root  system   0 Dec 13  1996  /usr/local/etc/forwards/bob.forward

and if that file is empty, bob's mail will always be delivered locally, no matter what bob puts in his ~/.forward file. For experienced users you can omit their files from the /usr/local/etc/forwards directory, thus enabling their use of their /.forward files.

#### 22.8.3.3 The LogLevel option

The sendmail program normally logs a great deal of useful information via syslog (see Section 26.1.1, "syslog(3)"). There will be times, however, when the normal amount of information is insufficient. Consider, for example, that some outsider is using your site to forge mail. Since this is done over an SMTP connection, it would be handy to have both sides of all SMTP conversations logged. You can do this with the `LogLevel` (`L`) option (see Section 34.8.33):

>     O LogLevel=12       V8.8 and above to log SMTP

Beginning with V8.8 sendmail, a level of 12 causes both sides of every SMTP conversation to be logged. That logging looks very similar to the logging produced by verbose mode (see Section 4.2, "Verbose (-v)").

Note that after changing the log level in your configuration file you will need to restart the daemon. With V8.7 and above sendmail you restart the daemon like this:

>     # kill -HUP `head -1 /etc/sendmail.pid`

Be aware that a log level of 12 produces a huge amount of output. Be prepared to prune your log files more often than usual.

#### 22.8.3.4 The PostmasterCopy option

The `PostmasterCopy` (`P`) option (see Section 34.8.46, PostmasterCopy (P)) causes a copy of every bounced message to be delivered to a named user. Usually, that user is the person who handle email problems. But since clumsy intrusion attempts can result in bounced mail, there will be times when bounced mail should also be delivered to the security administrator. Consider the following:

>     --- Transcript of session follows ---
>     ... while talking to your.site.domain.:
>     >>> RCPT To:<root@your.site.domain>
>     <<< 550 cannot open /tmp/.../getshell: No such file or directory
>     550 cannot open /tmp/.../getshell: No such file or directory

This bounced mail message indicates that someone tried to become root by breaking through your aliases database.

Users are added to the list of those who get copies of bounced messages with the `PostmasterCopy` (`P`) option:

>     O PostmasterCopy=postmaster,securitymaster

>                                        added

Here, `securitymaster` (probably an alias to a real user) was added.

#### 22.8.3.5 The PrivacyOptions option

The `PrivacyOptions` (`p`) option (see Section 34.8.47) is used to limit the amount of information offered to the outside world and to limit other kinds of access. The most restrictive setting for the `PrivacyOptions` (`p`) is probably best:

>     O PrivacyOptions=goaway,restrictmailq,restrictqrun

This setting disables the `expn` and `vrfy` SMTP commands, requires other sites to identify themselves before sending mail, and also limits access to the mail queue directory.

As a general rule it is best to begin with tight security. This minimizes your risk at the start and allows you to cautiously ease restrictions at a comfortable rate. Beginning with loose restrictions may force you to tighten restrictions in a panic when it is least convenient to do so.

#### 22.8.3.6 The SafeFileEnvironment option

Beginning with V8.7 sendmail, the `SafeFileEnvironment` option (see Section 34.8.58, SafeFileEnvironment) determines how delivery will be made to files. Ordinarily, sendmail will deliver to anything, provided that it has permission to do so (see Section 24.2.2, "Delivery to Files"). It can, for example, deliver by appending to ordinary files or by writing to a device such as /dev/log.

If the `SafeFileEnvironment` option is declared, sendmail will only deliver to ordinary files. This improves security by preventing anyone from scribbling over sensitive things, such as directories and devices. (Beginning with V8.8 sendmail, it is still okay to write to /dev/null even though this option is set.)

The `SafeFileEnvironment` option can also be used to define a directory under which all files that will be appended to must exist. This may inconvenience some users but will generally improve the security of your site. We recommend:

>     O SafeFileEnvironment=/path

This takes care of both security enhancements. Of course, you will need to create the directory specified in `/path` and modify all path references in your aliases file before actually enabling this.

If all you want to do is prevent writing to directories and devices, and if you do not want to place all files in a special path, you can accomplish this by defining `/path` as the root directory:

>     O SafeFileEnvironment=/

#### 22.8.3.7 The TempFileMode option

The `TempFileMode` (`F`) option (see Section 34.8.68) specifies the mode (file permissions) to give temporary files and queue files. In general, all files that are created by sendmail should be considered proprietary for safety's sake. We recommend a setting of:

>     O TempFileMode=0600

With this narrow setting, the risk of accidental or malicious easing of permissions of your mail archive directories or queue becomes less of a risk.

### 22.8.4 The /etc/shells file

To prevent certain users from running programs or writing to files by way of the aliases or ~/.forward files, V8 sendmail introduced the concept of a "valid shell." Just before allowing delivery via an alias such as these:

>     |"/some/program"
>     /save/to/a/file

the user's password entry is looked up. If the shell entry from that password entry is a valid one, delivery is allowed. A shell is valid if it is listed in the /etc/shells file. If that file does not exist, sendmail looks up the shell in its internal list that looks (more or less) like this: [19]

> [19] This is an amalgamation of many vendor lists. See conf.c in the source distribution for details.

>     /bin/bsh
>     /bin/csh
>     /bin/ksh
>     /bin/pam
>     /bin/posix/sh
>     /bin/rksh
>     /bin/rsh
>     /bin/sh
>     /bin/tsh
>     /usr/bin/bsh
>     /usr/bin/csh
>     /usr/bin/keysh
>     /usr/bin/ksh
>     /usr/bin/pam
>     /usr/bin/posix/sh
>     /usr/bin/rksh
>     /usr/bin/rsh
>     /usr/bin/sh
>     /usr/bin/tsh

With this technique it is possible to prevent certain users from having sendmail running programs or delivering to files on their behalf. To illustrate, consider the need to prevent the ftp pseudo-user from misusing sendmail:

>     ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:/no/shell

Here, any attempt by ftp to send mail through a program or into a file will fail because the shell /no/shell is not a valid shell. Such mail will bounce with one of these two errors:

>     User ftp@here.us.edu doesn't have a valid shell for mailing to programs
>     User ftp@here.us.edu doesn't have a valid shell for mailing to files

Note that unusual circumstances may require you to allow users with invalid shells to run program or deliver to files. To enable this for all such users (as on a mail server with restricted logins), place the following line directly in the /etc/shells file:

>     /SENDMAIL/ANY/SHELL/

To enable this for selected users, just replace their shell with a bogus one that is listed in /etc/shells:

>     ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:/bogus/shell

We recommend that all pseudo-users (such as bin and ftp) be given invalid shells in the password file and that /SENDMAIL/ANY/SHELL/ never be used.

22.7 Forged Mail |  | 22.9 Pitfalls